home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
EnigmA Amiga Run 1995 October
/
EnigmA AMIGA RUN 01 (1995)(G.R. Edizioni)(IT)[!][issue 1995-10][Aminet 7].iso
/
Aminet
/
comm
/
fido
/
SHELTER275.lha
/
XPRS
/
xprslk.doc
< prev
next >
Wrap
Text File
|
1994-11-29
|
7KB
|
138 lines
xprslk.library
Robert Williamson
This library is an implementation of the SEAlink protocol
SEAlink is (C) COPYRIGHT 1986,87 by System Enhancement Associates, Inc.
xprslk.library implements the SeaLink protocol for EMSI sessions, term
programs and BBSs. SEAlink is a sliding window protocol with overdrive and
resync options. The following is a description of that protocol derived
form FTS-007, FSC-0010 and FSC-0018.
The intent of SEAlink is to provide a file transfer protocol that does
not suffer from propagation delays, such as are introduced by satellite
relays or packet switched networks. Actual tests have shown that SEAlink
is capable of virtually eliminating propagation delays and turnaround
delays. File transfers which normally suffer a degradation of 50% or more
due to satellite relays, proceed as fast as local transfers. Even
transfers within the local exchange are speeded up by up to 20% at 2400
baud by the elimination of turnaround delays. Large volume tests show that
SEAlink is capable of coming to within 2% of the theoretical minimum time
for data transfer.
SEAlink adds a block number to the ACK and NAK used in XMODEM.
XMODEM/CRC uses a "C" in place of a NAK to indicate CRC error detection.
SEAlink follows this convention, and supports either checksum or CRC. For
brevity, this document will use the term NAK to mean either a true NAK (hex
15) or a C (hex 43).
From the receiver's point of view, it does not matter if the
transmitter is using sliding window or not. The receiver simply sends ACK
and NAK packets as appropriate. Any XMODEM driver tested to date will
simply ignore this excess data behind the ACK or NAK.
From the transmitter's point of view, it just barely matters if the
receiver can handle sliding window. The transmitter always acts as if it
is sending sliding window, but varies the window size. If it is seeing
valid block numbers and check values behind the received ACKs and NAKs, it
sets the window size to six blocks. Otherwise, it sets the window size to
one block. The result is that it only "sends ahead" if the receiver can
handle it.
SEAlink is also capable of passing system dependent information, such
as true file size and time of last modification. This data is passed in a
special header block. The header block looks exactly like any other block,
except that it is block number zero. Protocol capbilities are also
indicated in this block.
Of special interest is the byte flag at offset 40 in block zero. This
is the "Overdrive flag", and is used to trigger streaming mode for
high-speed, half duplex modems. In Overdrive mode the receiver stops
sending ACKs for the bulk of the file transfer, thus facilitating transfers
over a half-duplex connection. Overdrive is never required over a full
duplex connection. Overdrive requires that the basic link be effectively
error free. Overdrive is disengaged aotomatically if either of the
following conditions are encountered.
The transmitter will disengaged overdrive if it detects that the
receiver has dropped out of overdrive, or does not support overdrive.
The receiver will disengage overdrive if it finds itself receiving an
excessive number of bad blocks, as Overdrive requires an error-free link.
Another byte in block 0 indicates the Resync protocol enhancement that
allows the protocol to pickup broken transfers were it was interrupted. As
a side effect transmissions of exact duplicate files (from whatever source)
will only result in the two systems exchanging EOT and thus saving a lot of
transfertime and costs.
Any field which the transmitter cannot support should be set to all
zeros. Conversly, the receiver should ignore any null fields. The
receiver may ignore any field which he cannot support.
The number of blocks in the sliding window is set depending upon the
baud rate, with a minimum of 6 (768 bytes) and a maximum of 127 (16256
bytes). When OverDrive is enabled, the window is the size of the file being
sent.
If more than 10 ACKS are received during a session, it is assumed that
the remote does not support OverDrive and it is disabled.
If more than 10 NAKS are received during a window, the slide is reduced
to 1 block.
XPR options:
B - allow use of long filenames (32 chars)
this uses the mailer field of the Sealink header
O - OverDrive, receiver does not ACK
R - allow ReSync (resume)
L<bps> - Link rate
Defaults: BN,OY,RN,L0
wpl concerns:
If used with a mailer written in the WPL language, the name of the
transmitting program in the SeaLink header will be set to the value of the
WPL variable "$(host.mailer)". Otherwise, the transmitting program name is
set to "XPRslk".
XprSetup does not read any variables, so you must set option L to
$(baud) so that all calculations are based upon the actual link rate and
not the locked rate.
XprSetup makes an XPR library ready for a transfer. The first parameter
given is the xpr library name, and the second parameter is a string passed
to the xpr library with XProtocolSetup(). The variable $(XprSetup) is set
to the numeric return of XProtocolSetup(). A value of 0 indicates a
failure, otherwise the setup was successful.
Return Values in $(Setup) are or'ed from the following:
XPRS_FAILURE 0x00000000L
XPRS_SUCCESS 0x00000001L
XPRS_NORECREQ 0x00000002L
XPRS_NOSNDREQ 0x00000004L
XPRS_HOSTMON 0x00000008L
XPRS_USERMON 0x00000010L
XPRS_HOSTNOWAIT 0x00000020L
XPRS_NOUPDATE 0x00008000L
XPRS_XPR2001 0x00010000L *
XPRS_DOUBLE 0x00020000L *
* Note: private jammail versions of wpl.library require both returned
to enable dual-status display. This is WRONG. Only XPRS_XPR2001 should
trigger use of dual-status display. Therefore support for dual-status
display, while in the sources, is disabled via a compile define for this
release.
WARNINGS:
This is most certainly a BETA release.
Presently ReSync is not enabled, turning it on will result in failed
sessions.
OverDrive does not check all possible error conditions as yet. Strange
results are encountered depending upon what program the remote is running
and/or how the remote has setup his options.